A computer software architecture is a general term that includes defining the way in which software applications are developed, deployed and executed upon computer systems. The computer systems include both the hardware and the operating system that facilitate execution of the software. One such software architecture, of which MICROSOFT's COM/COM+ is a particular well-known example, embodies a component approach to development, deployment, and execution of computer software. In a component-based software approach, an application executable comprises a set of building blocks, or components, that are defined by an interface and a set of functions (e.g., methods) rendered by the component via the interface. In the case of COM/COM+ components, the COM object components (including methods and/or data) are compiled into binary executable modules. The components, depending upon their mode of deployment (i.e., in-process or out-of-process) are deployed as either .DLL files (in-process) or .EXE files (out-of-process). The present invention concerns the out-of-process form of software component.
All components are not required for particular executions of an application. Thus, the components are dynamically created (e.g., instantiated) during the course of execution of an application. For example, a server component object is loaded and a process space created for the server component (e.g., COM server) by the operating system in response to a particular call from an executing client component (e.g., COM client) for a service rendered by the server component. It is noted that in the context of the present invention, a client component can also represent itself to other components as a server. Thus, the present invention is applicable to client-server, peer-to-peer, and hybrid environments where clients represent themselves to other components as servers.
Once created, the components consume computing resources (e.g., CPU time, RAM, etc.). Thus, where many components are actively competing for a limited set of computing resources, a criteria should be imposed upon the components to restrict their execution, including when they are purged from the active process space of a computer system. If the components are not currently needed, then they should be removed from the active process space of a computer system to free up resource consumed by the unneeded components. Furthermore, not all components are of equal importance within a computing environment. Thus, component management mechanisms have been implemented for determining when a particular component is not presently needed, and then removing the component from the active process space of a computer system. In particular, known component management schemes detect when a server component (e.g., a local out-of-process COM server) is no longer referenced by any client components, and then purge the server component from the active process space.
Known component object arrangements (i.e., COM/COM+) utilize reference counters to facilitate monitoring the number of COM client components using particular COM server component interfaces. A COM server executable is launched in response to a first request by a COM client and a reference counter for the COM server's referenced interface is incremented to reflect the use. When the reference counter for a particular COM server interface reaches zero, the COM server component is able to delete objects that are only serving the particular interface. Furthermore, when the reference counters for all interfaces of the COM server reach zero, the COM server shuts down, thereby returning consumed resources to a computer system upon which it executes.
Two known schemes are currently used to shutdown a COM server at an appropriate time after it is determined that no clients are presently using one of its interfaces. The first scheme requires the COM servers and clients to increment and decrement an interface reference counter to reflect the clients' use of the COM servers' interfaces. This procedure utilizes the well known AddRef and Release methods on the COM server interface. When a client requests an COM server's interface, the server increments the reference counter by calling the AddRef method. When a client currently referencing an interface no longer requires use of the interface, the client calls the Release method on the COM server's interface to explicitly end the connection. The Release method decrements the reference count for the referenced interface. Thus, when all clients have explicitly released their references to the interfaces to provided by the COM server, all the interface reference counts equal zero and the COM server can shut down.
There are at least two shortcomings to the above-described scheme. First, if a client does not explicitly release the reference to an interface (e.g., the client process freezes and is killed by the operating system), the release command is never sent. A period of time can lapse before the absence of the client is registered, and thus a COM server can reside in the active process space well after the clients that referenced it have terminated. In a particular example, a COM ping timeout mechanism involving a server process stub and client process proxy exchange ping packets every two minutes. If the stub experiences three failed ping attempts with the client proxy, then the server releases all interfaces associated with the particular client. Second, if the client process is improperly programmed and terminates without calling the Release method, then the same undesirable result is achieved as the first shortcoming.
The second known scheme relies upon a COM Runtime system interface, i.e., IExternalConnection to increment/decrement interface connections. COM Runtime makes the first call to the interface when the server is initially called by a client component. A stub manager on the server process including the COM server calls the COM server to add/release connections to clients and thus increment/decrement the reference counters. When the external reference count reaches zero, the server object explicitly calls a disconnect method on itself. Thereafter, the stub manager of the server process calls a release method on the server object to destroy it. If COM client shuts down normally, but is unaware of the reference release function, an “uninitialize” call known by all COM clients will trigger the server to call the reference release method. The second approach handles the case of the unaware COM client. However, the second approach does not handle the instances where a client crashes before “uninitializing.”
The above examples exhibit just one of many shortcomings of the prior art with regard to the general lack of management capability of a server process over the client processes that reference its interfaces.